【レポート】CUS-86：商取引の活性化は与信システムの革命が促進する。ネットプロテクションズが挑む Amazon ECS と Amazon SageMaker を用いた決済・金融のマイクロサービス化戦略について #AWSSummit

AWS Summit Online Japan 2020

#Amazon SageMaker

#Microservice Architecture

#AWS Step Functions

#決済

#Amazon Elasticsearch Service

夏目祐樹

2020.10.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、CX事業本部の夏目です。

今回はAWS Summit Onlineのオンデマンドセッション「CUS-86：商取引の活性化は与信システムの革命が促進する。ネットプロテクションズが挑む Amazon ECS と Amazon SageMaker を用いた決済・金融のマイクロサービス化戦略について」についてのセッションレポート(文字起こし)になります。

導入

ネットプロテクションズの沢田と申します。
本日は普段語ったことのない決済の裏側の話をさせていただきます。
短いお時間ですが、どうぞよろしくお願いいたします。
では早速スライドに移って参ります。

タイトル

商取引の活性化は与信システムの革命が促進する。と題してお話させていただきます。

自己紹介

まず自己紹介いたします。
今日お話しする沢田智希と申します。
ネットプロテクションズ入社の5年目、昨年発足したデータサイエンスグループにて、データレイクの構築、データサイエンス研修などデータドリブンな組織開発に尽力しています。
得意分野をナレッジマネジメント、データサイエンスグループに入る前に、去年ですね、Slack の全社導入などをやっていました。
今やっていることも含めてい社内の情報格差をなくすことに尽力しています。

本日の話

そんな私が本日は、後払い決済を提供するネットプロテクションズが、オンプレミス環境から AWS 上でのマイクロサービスへ移行した、というお話とその苦労話をお伝えした上で、最後に少しだけ、今後の決済金融領域におけるデータ活用戦略についてお話いたします。

目次はこうなっています。

会社、事業の概要

では早速、会社のご説明をいたします。
決済クレジットカードも含めて、使ったことあるけど中の仕組みは知らない方が多いと思います。
まずは軽い事業説明とともに AWS への大規模移行を実施した背景をお伝えいたします。

ネットプロテクションズと申します。
設立は右上に書いてありますように、2000年、20年経ちました。
当時はそんなの絶対成り立たないよと言われたサービスを、2002年にサービス提供し始めてから約20年。
今は複数事業を展開していますが、どれも後払い決済、そのパイオニアとして市場を牽引しています。

では後払い決済、なぜ絶対成り立たないよと言われたのか。
それはネット通販において、見ず知らずの人の代わりに、弊社ネットプロテクションズが立替払いをするというところにあります。
このユーザー様の料金を後払いすることを許す以上払ってもないものはリスクというのを誰かが背負わなければいけません。
ネットプロテクションズではショップ様の代わりに、100%それを担保しながらも利益を出し、ビジネスとして成り立たせています。
この右に出しておりますメイン事業 NP後払いにおいては、年間流通額が2500億円、年間利用者数は1350万人と、おかげさまで10人に1人が使ったことのあるサービスとなっています。

NP 後払いご利用いただいたことありますか。
10人に1人利用しているためもしかしたら使ったことがあるかもしれません。
でも、気づいていない人が少なくない、それぐらい利用にあたっての特別の対応がいらないサービスです。
具体的には、クレジットカードを作成利用するときのような作業は一切不要、ネットショッピングで当たり前に入力する、左に書いているような、氏名、住所、電話番号のみで、お客さまに利用いただいています。
なのにお支払いは、受け取りの後で良い。
その簡単さ、便利さゆえに、リピーターも多く、たくさんのお客様にご利用いただいています。

私たちにとって一番大事なのは、審査です。
ユーザー様の未払いはそのまま私達の損失、わずかな手数料を積み重ねて利益にしているため、一件の未払いで利益が大きく吹っ飛びます。
そのため、未払いリスクをどう抑えるかは、社員誰もが意識するポイント。
セールスであっても、カスタマーサービスであってもサービスとシステムへの深い理解が必要とされ、組織一丸となって事業運営をしています。
しかし、私たちはほんのわずかな情報しかユーザー様からもらえません。
だからその分ショップ様の審査もしております。
新しく営業するときも、未払いリスクを事前にしっかり検討、ショップ様にいただく手数料と照らし合わせて、ちゃんとビジネスできるのか、利益が出るのか考えながら営業しています。
ゆえに、私たちは、新市場の開拓を慎重に進めてきました。
例えば家電、現金化しやすいものは不正利用される可能性が高いため、 NP後払いを導入したいですといただいても、泣く泣くお断りしてきました。

17年越しの課題

そんなリスクとバランスをとってきた NP後払いではサービスリリースから17年、当初からは、サービス全体の仕組みを大きく変わらずやってきた中で、課題もありました。

具体的にはこの三つ、一つずつご説明していきます。

まず、審査システムの改善です。
17年間動いてきた審査システムに成長限界が来ていました。
NP後払いの基本はクレンジング、この人は支払わないというデータを溜めることが利払い率低下に一番効きます。
しかし、それだけでは実払いを防げません。
NP後払いの不正利用を検知する審査モデルの構築も重要です。
その審査モデルの改善が難しい状態がずっと続いていました。
システム構成上、最初に選んだ機械学習アルゴリズム以外使えない、アルゴリズムが決まった状態で決済データを使ってチューニングする、それだけで審査モデルを更新してきました。
行えることは、今お伝えしたような、あらかじめ決められたアルゴリズムのチューニングのみ。
また、このモデルのチューニングの作業は少し難しかったため、ほとんどできる人がいませんでした。
結果、更新も6年越しに一度されるだけというのが、審査システムで起こっていたことです。

次に、イレギュラー対応、こちらも悩みの種でした。
17年も経つとイレギュラーがあるのが当たり前な状態になってきます。
元々は、ユーザー様の郵便受けに請求書が届き、14日以内に支払うと、もし14日過ぎてしまった場合は、支払うまでNP後払いは使えないという単純なサービスです。
しかし、サービス運営をする中で、請求書は郵送ではなく箱に詰めて一緒にお送りしたい。
青汁、数ヶ月にわたって定期的にお届けするので、初回の支払いが遅れても大目に見てほしいなど様々な要望をいただくようになりました。
これらは、システム内ではイレギュラー対応としていたもの。
しかし、NP後払いの売り上げ上位を占める通販大手のショップ様には当たり前に求められます。
今から5年ほど前には、大きなショップ様も増えてきて、上位20%のショップ様が80%の売り上げを作っているような状況。
この状態では、イレギュラー対応として増やしてきたオプションがむしろ主流になっていました。

最後の課題、それはシステム開発が追いついていないこと。
多分にもれずネットプロテクションズもエンジニア、データサイエンティストが足りていません。
審査、イレギュラー対応、先程伝えしたこれらの品質セールス、カスタマーサービス、エンジニアの三者でバランスをとって対応してきました。
しかし、サービスが大きくなるにつれて、保守運用の部分が増えてきます。
特に大手企業様にも導入していただいている今では、先方からいただく高いサービス品質に合わせて、24時間サポートなどの必要性も出てきます。
本来はサービス企画に人をはりたい。
しかし、そうして企画に人をたくさんはると、システムが火を噴く障害が起きて、企画にはれなくなる。
今ご覧いただいてるように、17年一つのシステムを中心に育ててきたからこそ、少しずつ回収しにくさも積み上がってきました。
このような三つの大きな課題が、17年経った今、見えてきたところでした。

これらをデータセンターから AWS に代行する中で、一つずつ解決しています。

移行時に行ったことは大きく二つ、得られた効果は三つあります。
一つ、マイクロサービスにして、審査システムをアップデートしやすく、また個別対応しやすくしました。
もう一つ、フルマネージドサービスを利用することで、サービス作りに注力しやすくしました。
一つずつ具体的にお話していきます。

一つ目、モノリスだったサービスを大きく分解し、マイクロサービス構成にしました。
具体的にはご覧いただいたアーキテクチャに変えています。
審査といっても、実は何を審査するのか、なぜ審査するのかが細かくわかれます。
17年という長い経験をもとに審査プロセスを細かく分解し五つのような構成にしました。
この構成にすることで、各部分の大幅な改善はもちろん、前は6年に1度しか更新できていなかった審査システムの継続的な改善などもできるようにしています。

ここで審査の仕組みについて、少し詳しくお話いたします。
審査では大きく二つ見ています。
左に見えるこの人を払えるんだろうかという支払能力・意思の部分、また右のようなこの人はそもそも払う意思があるんだろうかという不正利用の部分、この二つを見ています。
今回は AWS への移行に合わせて、右の不正利用の部分を Amazon SageMakerでできるようにしました。
この払う意思がないケース、集団詐欺などでユーザー様の事前登録はいらないという NP後払いのサービスの仕組みを逆手にとって、あの手この手でいろんな詐欺をやってきます。
ここが曲者でした。
新しいショップ様で利用できるようになると、すぐに詐欺の餌食になる。
そんなこともよくあります。
従来は、この審査システムで判断しにくいものを、人の目で審査することで、未払いを防いできました。
しかしここ、人の目を通すため、審査結果をショップ様にお返しするまでかなり時間をいただきます。
具体的には1時間いただいていました。
そちらを、今回 Amazon SageMakerを使うことで、リアルタイムで審査ができるようにしています。

先ほどからお話している Amazon SageMakerとは図のような機械学習プロセスを面倒な開発なく利用するためのサービスです。
ネットプロテクションズでは従来、下に書いている図の開発、推論の部分はシステム依存で手が入れづらく、ラベリングの部分は人の目で行っていました。
それらを今回まとめてSageMakerで行えるようにしています。

具体的には、ご覧いただいた構成で、不正検知モデル構築をSageMakerのみで行えるようにしました。
また、不正注文の判断に必要な情報は、 API 経由で追加できるようにしているため、今まではできなかったような細かいモデル構築ができるようになっています。
この結果、従来は1時間程いただいていた審査結果の返却のところが数秒でもちゃんと返せるようになったため、今までは導入いただくことができなかったテレビショッピングなど、新たな業界でも利用できるようなサービスになっています。

二つ目、ショップ様ユーザー様ごとに個別対応しやすいようにしました。
以前はすでにある機能を、違う使い方したり、いろいろ組み合わせたりしたっていうところを、より柔軟に行えるようにしています。
具体的には、この上に書いてある加盟店属性という部分と、右下の外部属性という部分を使っています。
ショップ様ごとに個別の対応することはもちろん、個別対応する上で追加が必要な情報があれば、右下の外部属性のところからAPI経由で追加できるようにしています。
ショップ様よりよくいただくご依頼としては、今審査をお願いした購入者様はお得意様なので与信を通して欲しいというものがあります。
例えばこういうものだと、お得意様リストを事前にいただいたり、お得意様かを判断できるAPIを共有いただくことで柔軟に対応できるようになっています。

また、この加盟店属性という部分では、NP後払い1事業だけではなく、他の決済事業の判定ロジックも載せる予定です。
以前は、この判定ロジック等審査プロセス全体が一つとなっていたため、 NP 後払いの審査しかできなかったのですが、今このように細かく分類したため、判定のロジックを追加するだけで、会社全体で同じ審査システムを使い回せるようになっています。

三つ目、サービス改善サービス構築に集中できるようにしました。
具体的には、フルマネージドサービスをたくさん利用しています。
フルマネージドサービスを使うことで、図にあるようなコードの量が大きく減り、構成もシンプルになりました。
結果として、エンジニア同士での引き継ぎがしやすくなったり、又は利益を生むビジネスロジックの構築に集中できるようになっています。

この影響は、弊社においてとても大きいと考えています。
ネットプロテクションズのビジネスはどれもショップ様とユーザー様を両方見ながらバランス良くリスクを抑えていくのが肝。
以前より与信ロジックを作る、システムを作る、サービスを作ることは、ショップ様に向き合うこのセールス、またはユーザー様に向き合うカスタマーサービス、そしてシステムを作るエンジニアの3者で行ってきました。
事業サービスありきのこの三つの部署だからこそ、社員は総合企画者以外で、企画職以外での採用はしていません。
そんな BisDevOps できそううの体制ではあったのですが、システム部分が追いついていませんでした。
事業の未来を描こうにも、今のシステムのあり方が、思考に制約をかける。
目下困っているショップ様、ユーザー様に応えて、今しかできない、今しか使えないシステムを作ってしまう。
事業は四つやっているけれども、どれもジャンルは後払い決済。
細かい違いはあれど、ビジネスモデルをほぼ同じ。
だからこそ、構成をシンプルにして、事業間のシステムナレッジのシェアができることが一番の強みになると考えています。

と、いいことばかり話してきましたが導入はもちろん、一筋縄ではいきませんでした。
今から、苦労話をお伝えいたします。

苦労したこと、それはAWS サービス選定です。
今回はシステム移行であるため、新しく作るものとかも少なく、要件もある程度見えていました。
なので、開発の中で一番時間を使ったのが実はサービス検証です。
自分たちが実現したいことに対して一つずつサービスの検証をしました。
今回は具体的に二つご紹介いたします。

一つ目、 AWS Step Functions高くつく問題。
今回のシステム設計当初はStep Functions というサービスで構築しようと考えていました。
審査プロセス、中がすごくですね、相互に絡み合っているところがあります。
こちらが可視化されるならば、便利だなあと思っていたんですが、コストを試算したところ、全然駄目でした。
もともと NP 後払いで未払いリスクを抑えるために、ユーザー様の利用上限金額を決めています。
結果、一件当たりの金額も小さく、利益も小さいため、Step Functions での課金体系である処理単位での課金では、ちょっとコストが高くつきすぎてしまう。
故に右に書いているような、先ほどご紹介した Elastic Container Service ECS を主体とした構成に落ち着きました。

二つ目、他で言うと DB 選定も苦労しました。
私達は取引ごとに今までの全ての取引と照合して結果を出しています。
そのため毎回億単位のデータと照合しつつ、数秒以内に結果を出すことが求められます。
検討の当初はDynamoDBいいなと思っていました。
とても早いなというのを聞いていたので、ただし、計算してみるとちょっと高い、高すぎる、払えない。
じゃあ今まで通り RDB 使おうとすると、スピードが厳しい。
データベースの構成を変えてグラフデータベースはどうだ。
ただ、こちらデータ構成を工夫しようにもデータの特性上難しい。
困ったので AWS さんに相談しても、このデータ量を聞いたことないですねと言われる。
リリース日は決まっていたのでハラハラしながらやっていました。
いろんな検証を進めていただき、結果として、 Elasticsearch を選定し、ハイパーパラメーターをきりきりきりきりチューニングすることで、安いコストと返答速度、両方とも満足できるような状態となっています。
このように、今でこそマイクロサービスとフルマネージドのメリットを純粋に享受できていますが、開発当初は気が気でありませんでした。